QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940283.txt

Internet Message Format | 1994-11-13 | 21KB

Date: Wed, 24 Aug 94 04:30:19 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #283
To: Ham-Digital


Ham-Digital Digest          Wed, 24 Aug 94       Volume 94 : Issue  283

Today's Topics:
                                (none)
                          Filters for TEKK's
                              HF Packet
                   MFJ 1278 - looking for software
                    MS400 4 port serial settings?
                            paKet6 Manual
                             PKTMON12.LZH
          Will my radio work as a packet station??? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 23 Aug 94 14:27:00 GMT
From: [e-mail]
Subject: (none)
To: [e-mail]

signoff ham-digital

------------------------------

Date: Mon, 22 Aug 1994 10:58:58 -0400
From: ftpbox!mothost!lmpsbbs!NewsWatcher![e-mail]
Subject: Filters for TEKK's
To: [e-mail]

In article <[e-mail]>, jkbe@lena (John Bednar) wrote:

> I am looking for suppliers that sell 21.4 Mhz IF crystal filters
> that I can stuff into a TEKK data radio. I'd like to experiment
> with higher data rates. Has anyone been through this before?
>
> John, WB3ESS
> [e-mail]

Try Piezo Technology  (Technologies??) in the Ft. Lauderdale, FL area.
Sorry, I don't have their phone number, but LD information for Area Code
305 should be able to find it for you.  As of a few years ago they had
filters for both 10.7 and 21.4 in several different bandwidths and options
for sharp skirts or minimal passband ripple.  At that time they were the
best US supplier I could find for such goodies.

--
Karl Beckman, P.E.                  <     If our English language is so  >
Motorola LMPS.RNSG.Analog Data      <  precise, why do you drive on the  >
(Square waves & round corners)      <  parkway and park on the driveway? >
   Opinions expressed here do not belong to or represent Motorola Inc.
Amateur radio WA8NVW                        NavyMARS NNN0VBH @ NOGBN.NOASI

------------------------------

Date: 23 Aug 1994 21:44:25 GMT
From: newsgw.mentorg.com!wv.mentorg.com![e-mail]
Subject: HF Packet
To: [e-mail]

In article <[e-mail]>, [e-mail] (David Zielke) writes:
|> I am in the process of examining the possibilities of using HF packet to
|> provide communication between my sailboat while at sea and land based e-mail
|> connections.  I have been a ham since the late 70's and have been inactive
|> for some time.  Suggestions of what kind of gear (HF rig, TNC, computer)
|> would be very helpful.  I will most likely be loading the backstay as an
|> antenna.

Plan to use amtor, pactor, clover, gtor, or clover.
Packet on HF is not actually very useful.
CLOVER is best, with the other protocols working well also.

|> Also, I am trying to decide between Intel based PC's and the Mac portables
|> (something like a 540 active monochrome in the mac line or a 486 33mhz
|> laptop in the intel world).

DOS/Windows Laptop.  MUCH software available for it, minimal software
available for any other computer.

If you end up using CLOVER, I'll see you on HF ...

   ...  Hank

--

Hank Oredson @ Mentor Graphics             Library Operations
Internet     : [e-mail]    "Parts 'R Us!"
Amateur Radio: [e-mail]

------------------------------

Date: 24 Aug 94 14:55:24 GMT
From: [e-mail]
Subject: MFJ 1278 - looking for software
To: [e-mail]

Hi and tnx reading this,
I am using an tnc 1278 from MFJ for some days by controlling the exellent
xp-terminal. I works well, but I would like to try some other software
especially for fax and sstv too. Is there someone who can give me hint where
I can find it i would be pleased.
tnx in advance es 73 de Wolfgang (DL7VWH)


Technische Universitaet Berlin                              :-%
Institut fuer Bergbauwissenschaften, Sekr. BH 3             :/i
Str. des 17. Juni 135, 10623 Berlin, Germany
Wolfgang Heise  -  VOICE: ##49-30-31425672  -  FAX: ..-31426797
possible on hamradio/packetradio too by [e-mail]

------------------------------

Date: 23 Aug 1994 00:54:30 GMT
From: munnari.oz.au!yarrina.connect.com.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!news.adelaide.edu.au![e-mail]
Subject: MS400 4 port serial settings?
To: [e-mail]

Does anyone have some docco on the MS400 PC 4 port serial card, as to the dip
switch settings for each port ? Ive worked a few out, but some have me bluffed,
also any info on whether the card is capable of interrupt sharing ?

thanks ... Rob

--
rob mayfield    senior technical analyst, australian submarine corporation p/l
[e-mail] vk5xxx@vk5xxx.#adl.#sa.aus.oc [phone]w

------------------------------

Date: Tue, 23 Aug 1994 22:06:33 +0000
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!metro.atlanta.com!mhv.net!news.sprintlink.net!demon!g1xgp.demon.co.uk!g1xgp@@.
Subject: paKet6 Manual
To: [e-mail]

AAPRA the Australian Packet Radio Group have published a Booklet Manual
of Tony Lonsdale's (VK2DHU) acclaimed paKet 6 program. AAPRA have
appointed Essex Packet Shareware to acts as their UK Agent. Anyone
interested in obtaining a copy/information, kindly contact the
undersigned:-

[e-mail]

73
Steve



   ------------------------------------------------------------------
   + Steve Blinkhorn    + G1XGP @ GB7WIG.#34.GBR.EU (Amateur Radio) +
   + AMPRnet            + [e-mail]      [44.131.16.147] +
   + Essex Packet Group + [e-mail]   (Internet)      +
   ------------------------------------------------------------------

------------------------------

Date: Tue, 23 Aug 1994 08:45:38
From: elroy.jpl.nasa.gov!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!sislnews.csc.ti.com!ken_durham.linear.sc.ti.com![e-mail]
Subject: PKTMON12.LZH
To: [e-mail]

PKTMON12 is supposedly a program to allow reception of packet radio signals
without an external TNC or multimode controller. It gets its input from the
radio speaker output through an op-amp attached to the PC serial port.
The signal is decoded and displayed on the Hamcom program terminal screen.
Both programs are shareware, but PKTMON12 was hard to find. I finally got it
by ftp from funet.fi. The problem is that the program is compressed and has
a suffix of LZH.

If anyone can tell me where to obtain a copy of whatever decompression
program is required for LZH, I would appreciate it.

de K5MBV

PS. My email should be working now.

------------------------------

Date: 23 Aug 1994 10:06:09 -0400
From: newstf01.cr1.aol.com!search01.news.aol.com![e-mail]
Subject: Will my radio work as a packet station???
To: [e-mail]

I have a Baycom modem that I got from A&A engineering.  I wish to hook it
up to one of my radios to run packet but I have heard that some radios do
not switch fast enough from transmit to receive?  My possible radios are:
Azden PCS-3000
Yaesu FT-207R
Icom 02-AT
Standard SR-C146A

Will any of these radios work without modification?
If not, can they be modified to work?
Please e-mail [e-mail]

------------------------------

Date: Tue, 23 Aug 1994 21:45:59 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!news.cac.psu.edu!ppp35.cac.psu.edu![e-mail]
Subject: Will my radio work as a packet station???
To: [e-mail]

In article <33cvoh$[e-mail]> [e-mail] (JoeSullivn) writes:
>From: [e-mail] (JoeSullivn)
>Subject: Will my radio work as a packet station???
>Date: 23 Aug 1994 10:06:09 -0400

>I have a Baycom modem that I got from A&A engineering.  I wish to hook it
>up to one of my radios to run packet but I have heard that some radios do
>not switch fast enough from transmit to receive?  My possible radios are:
>Azden PCS-3000
>Yaesu FT-207R
>Icom 02-AT
>Standard SR-C146A

>Will any of these radios work without modification?
>If not, can they be modified to work?
>Please e-mail [e-mail]

Hi Joe.

I am sure the Azden, Yaesu, and Icom will work just fine.  In fact, I
sometimes use my IC-02AT on packet.  I'm not sure about the Standard but
don't think it would have any problem.  In general, any rig will work but
those with solid-state T/R switching are preferred.  Some rigs may require
some adjustments to certain TNC parameters but that turns out to be no big
deal.

73, Chuck - K3CM

------------------------------

Date: Tue, 23 Aug 1994 16:48:17 GMT
From: world![e-mail]
To: [e-mail]

References <32d90d$[e-mail], <3306v8$[e-mail]>, <[e-mail]>
Subject : Re: Looking for DXCluster software

In article <[e-mail]>,
Gary Coffman <[e-mail]> wrote:
>In article <3306v8$[e-mail]> [e-mail] (Andrew B. White) writes:
>>While I agree with you that PC use of AX.25 is not the best for distributing
>>spots, it is, currently, the only game in town.
>
>Note that broadcast servers us AX.25 too, just UI frames instead of
>connected mode frames. The FCC has us locked into AX.25 wrappers for
>unattended third party use.
>
>>AK1A has something like
>>400 nodes installed around the world, and they all talk to each other (altho
>>the email facility comes close to being useless if the mail has to go more
>>than one hop).  Besides, if the network is configured as it should be,
>>with local users on one frequency and the inter-node link on another, I
>>am not sure that the amount of bandwidth required is an issue.
>
>While splitting the users off the backbone is essential to making the
>systems work well at all, it *does* increase the amount of bandwidth
>the systems tie up. The real problem is that connected mode bulletin
>distribution uses nearly 26 times the channel capacity of a broadcast
>server. That means in practice, at our current low channel speeds, that
>channels have to be *dedicated* to Packet Cluster activity rather than
>being timeshared with other packet uses. That's bad spectrum utilization.
>
>Of course faster channel speeds can help, and I note with approval
>that Packet Clusters seem to be among the first to embrace faster
>channel speeds (out of necessity), first jumping to 2400 baud and
>now going to 9600 baud. But that's only a less than 2 and less than
>9 increase in channel capacity respectively at best (actually much
>worse than that on a simplex frequency due to turnaround and overhead
>delays). But a simple change to a broadcast protocol would *immediately*
>give a nearly 26 fold increase in available channel capacity. Since it's
>*only software* (heh), the change could be relatively quick and painless
>too.
>
>Note, broadcast use would free up channels only by allowing more
>than 26 stations per cluster. The channel would still have to be
>dedicated to the broadcast server. But the server could also serve
>more than just DX spots with the excess channel capacity. It could
>also distribute other types of bulletins and files in it's idle
>time.
>
>I don't think most connected mode servers are a good use of packet
>resources any longer. Broadcast servers are so much more efficient
>that Cluster *and* BBSs should change over as rapidly as practical.
>There remain some cases where connected mode works best, like serving
>low density WANs that need digis to get coverage. For higher density
>areas, however, the broadcast server is very much superior for most
>uses. (Personal Email may remain an exception.) Perhaps we need to
>think about making broadcast the bulletin and file distribution default,
>and connected mode the exception, in future server designs.

Gary, I assume then that you favor the discontinuance of using TELNET and
FTP on top of TCP/IP in favor of a broadcast or multicast equivalent?

The big problem I see with "simply" replacing the use of connection-
oriented packets with UI frames for DX clusters is one of reliability.
Packet is an extremely UNRELIABLE data link. That has to be factored
in to any change which is made. There's nothing wrong with running over
unreliable media, you just have to account for that in higher level
protocols. At some point in the stack you must acknowledge frames, or
recognize (in the broadcast case) that you've missed frames, and ask
for repeats.

How is the PacketCluster machine to know that the UI frame with a DX
spot just got stomped by another station starting to transmit a frame?
Packet radio does NOT run with Collision Detection in the way that
Ethernet does. You cannot tell, when transmitting, that your frame
has just gotten munched.

Dan
--
---------------------------------------------------------------
Daniel Senie                 Internet:     [e-mail]
Daniel Senie Consulting                    [e-mail]
508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: 23 Aug 1994 01:31:09 GMT
From: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <32b56i$ot5@T
Reply-To : [e-mail] (Andrew B. White)
Subject : Re: Looking for DXCluster software


In a previous article, [e-mail] (Gary Coffman) says:

>While splitting the users off the backbone is essential to making the
>systems work well at all, it *does* increase the amount of bandwidth
>the systems tie up.

But if we move these users to another band (222/440/900 or whatever) we can
re-use the bandwidth, and accommodate the current users given current
equipment.

I am confused about how the broadcast server works.  Does each end-point
periodically transmit a poll to see if any messages were missed?  Or is
the assumption made that every end-point receives every broadcast error
free?  With UI frames, does each end-point "guess" whether the broadcast
was from the broadcast server base on what can be recovered from a
corrupted frame?  Does the broadcast server continuously repeat the last
N spots?

PacketCluster presently provides more than just spot information,
but the DX spots are the most important.  Without the ability for each
end-point to confirm receipt or request fills, it seems to me we have no
better a system than the old 2m voice net (actually not quite that bad) or
the 2m Baudot net we used to use in the 70's.  If fill requests do not
occur on the broadcast frequency, then we need a second channel for
email transmission, listing old DX spots, searching the callbook, etc.

How would that work with the broadcast server?

73, Drew
--
*-----------------------------*-------------------------------------*
|    Andrew B. White  K9CW    |    internet: [e-mail]    |
|    ABW Associates, Ltd.     |   phone/fax: [phone]           |
*-----------------------------*-------------------------------------*

------------------------------

Date: Mon, 22 Aug 1994 10:38:16 -0400
From: ftpbox!mothost!lmpsbbs!NewsWatcher![e-mail]
To: [e-mail]

References <32d90d$[e-mail], <3306v8$[e-mail]>, <[e-mail]>
Subject : Re: Looking for DXCluster software

In article <[e-mail]>, [e-mail] wrote:

> In <3306v8$[e-mail]>, [e-mail] (Andrew B. White) writes:
> >
> >In a previous article, [e-mail] (Gary Coffman) says:
> >
> >>Yes, $400 is excessive. It's excessive because cluster is such a bandwidth
> >>wasting kludge. (Ok, it's a *useful* kludge, but kludge it is.) You can
> >>use free broadcast server software sending the info *2* times, one uplink
> >>and one broadcast (Pacsat protocol), instead of *27* to accomplish the
> >>same DX spot reporting. That's much more bandwidth friendly. Fills can be
>
>
> >While I agree with you that PC use of AX.25 is not the best for distributing
> >spots, it is, currently, the only game in town.  AK1A has something like
> >400 nodes installed around the world, and they all talk to each other (altho
> >the email facility comes close to being useless if the mail has to go more
> >than one hop).  Besides, if the network is configured as it should be,
> >with local users on one frequency and the inter-node link on another, I
> >am not sure that the amount of bandwidth required is an issue.
>
> I also agree that AX.25 is not the best protocol for sending DX spots but
> PacketCluster is an AX.25 application that requires the minimum equipment
> on the user end.  A radio, TNC, and dumb terminal is the user investment. It
> would seem that to implement a more efficient protocol would certainly require
> a computer on the user end to sort things out.  Some of the OF's barely mastered
> getting a dumb terminal to talk to a TNC, it would be real interesting watching
> them trying to become computer literate. Hi..
>
> But if someone came out with a system that offered enough advantages over the
> current Cluster software, I think it might catch on. There are many problems
> with PC that could be overcome by a more robust protocol which would be very
> attractive to the sysops.  My own feeling is that PacketCluster needs competition
> or many of the problems with it are not going to be solved.
>
> Rick Craig, N6ND
> [e-mail]

Well, I'm no software writer or DX Cluster user, but I'm still a ham and we
all offer opinions, solicited or otherwise.  I'm NOT offering to write this
update or even beta-test it, but let me toss one suggestion onto the pile:
1)  Take a look at the APRS software by Bob Bruninga WB4APR and note how he
uses the beacon message to communicate location data without requiring
"ack"s from every recipient.
2)  Apply the same idea to Packet Cluster, possibly fitting in some other
improvements at the same time such as the APRS location.  This would soothe
Gary's very legitimate distress about packet channel loading.
Any station beaconing in the proper format could be "logged in" to P-C if
their APRS coordinates were within a reasonable distance of the P-C host
area.  Full 2-way connects would not be required unless the operator needed
the FULL P-C BBS services; persons wanting only the DX spots could simply
watch the beacons go by.  In fact, that's what I do most of the time to
avoid loading the PacketCluster frequency with unneeded acks, but it is
frustrating to watch the same spot go by 64 times when P-C is fully
occupied.
3)  If someone can convince K1EA and WB4APR to work together, I'll bet that
each of them can find at least one more way to improve the combined
software and two more applications that we haven't yet thought of.
Synergy, cooperation, and talent arte a combination that is almost
impossible to beat (unless your name is Bill Gates, anyhow!).

--
Karl Beckman, P.E.                  <     If our English language is so  >
Motorola LMPS.RNSG.Analog Data      <  precise, why do you drive on the  >
(Square waves & round corners)      <  parkway and park on the driveway? >
   Opinions expressed here do not belong to or represent Motorola Inc.
Amateur radio WA8NVW                        NavyMARS NNN0VBH @ NOGBN.NOASI

------------------------------

End of Ham-Digital Digest V94 #283
******************************